Rate control is essential for media streaming over packet networks. The challenge in delivering bandwidth-intensive content like multimedia over capacity-limited, shared links is to quickly respond to changes in network conditions by adjusting the bitrate and the media encoding scheme to optimize the viewing and listening experience of the user. In particular, when transferring a media stream over a connection that cannot provide the necessary throughput, several undesirable effects arise. For example, a network buffer may overflow, resulting in packet loss causing garbled video or audio playback, or a media player buffer may underflow resulting in playback stall.
There are several different mechanisms to implement multimedia transport over packet networks. The first category of media network transports is streaming protocols, such as the Real Time Protocol (RTP). Streaming protocols are specifically designed to transport multimedia information with explicit timing information, and packets are generally expected to be sent at the time the media frame(s) in the payload are due.
Another category is pseudo-streaming. The most commonly used transport protocol for pseudo-streaming is Transmission Control Protocol (TCP), designed originally for bulk data transfers. As such, TCP does not explicitly indicate the timing information of the media in the payload. TCP is used to merely transfer a media clip (such as, e.g., .flv or .mp4 files). The media time information is implicitly sent within the media clip format, and the player simply plays back the clip as portions of it are downloaded. HTTP is commonly used as the download protocol over TCP
In the case of streaming protocol transports, standard bodies have recommended protocols, or extensions to protocols, to address the issue of transmission flow control and the implementation of bitrate management algorithms. Internet Engineering Task Force (IETF), in RFC 3550, specifies Real-time Transport Control Protocol (RTCP) as a companion to RTP and the fundamental building block to implement bit rate/packet rate control in RTP streaming media. Several extensions to RTCP, suited for high capacity networks, follow this original recommendation. Other proprietary protocols such as Real Time Messaging Protocol (RTMP) feature similar mechanisms.
Pseudo-streaming transport, on the other hand, usually do not require additional protocols for flow control. TCP itself uses its native endpoint feedback to perform flow control over its connections. TCP packets are identified by packet sequence numbers, which are acknowledged in the opposite direction via acknowledgement (ACK) packets. ACKs are unaware of the type and properties of the payload, thus making it difficult to implement a bitrate management algorithm for pseudo-streaming.
There are several challenges encountered while delivering a multimedia session over packet wireless networks. These challenges can include:                Sudden adjustment of nominal transmission rate: Due to interference, fading, etc, 3+G networks negotiate physical layer parameters on the fly. Nominal transmission bitrates can change by a factor of 10. In both pseudo-streaming and streaming sessions, the most immediate effect is playback stalling due to buffer depletion.        Packet loss: caused by either link transmission errors or by network congestion.        Reduction of effective bandwidth: The wireless link is a shared resource at Layer 2, with MAC (Media Access Control) mechanism and scheduling. This means that an increased load presented by other wireless terminals in the same sector can reduce the effective bandwidth or capacity that a terminal will see.        Limited capacity: Available capacity can typically be a fraction to that obtained in traditional wireline internet access technologies, where currently capacity is not an issue. Fixed internet media sessions in video portals can typically offer to the network loads between 250 and 800 kbps. Despite the fact that current 3G cellular networks can sustain throughputs of 500 kbps and above, the total bitrate budget for a cellphone wireless multimedia session is typically kept under 150 kbps to ensure scalability.The issues described above could affect streaming and pseudo-streaming sessions, making adaptive bitrate management essential to achieve good user experience.        
For wireless mobile phones with RTP or similar streaming protocols, the implementation of this adaptive bitrate management is challenging due to:                Infrequent and incomplete network state information. The typical wireless media player supports RTCP receiver report as defined in RFC 3550, and the report generation frequency is fixed. As a result, the network state information obtained at the sender end is limited and sporadic. In its Packet Streaming Service specification, 3GPP recommends several extensions to the basic IETF RTCP Receiver Report (i.e. RTCP Extended Reports, or XR). Unfortunately, very few handsets implement these enhancements;        Different media streams are handled separately. Despite the fact that they are both transmitted over the same network link, audio and video streams are handled separately by RTCP. Both RTCP reports provide state information about the same network, therefore a joint analysis; and        Low media bitrates are typically used. The bitrate budget for a wireless multimedia session is generally very low (under 150 kbps). Any attempt to reduce the audio or video bitrates can have large perceptual impact on the session.        
In the case of pseudo-streaming sessions, TCP handles lost packets by requesting retransmissions. Issues, such as quality degradation due to dropped media packets, are therefore non-existent even though the actual occurrence of packet loss in the system layer leads to increased latency in the data stream, increasing the probability of media players stalling due to empty buffers. The following notable problems occur:                The feedback provided by TCP's ACK packets is completely unaware of the media time being transferred        An HTTP download over TCP will send as much of the media file as possible and as quickly as possible.        Additional components can be required at the receiver to cope with the fact that the internal state of TCP is not directly available to media applications.        